home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr49 / xpkmash3.zip / XPKMASH.DOC next >
Text File  |  1995-02-14  |  6KB  |  160 lines

  1.  
  2.                                     MASH
  3.                    Another LZRW based compression algorithm
  4.                         Version 1.77 (14 Feb 1995)
  5.                       Copyright 1994 Zdenek Kabelac
  6.  
  7.                                 License/Disclaimer
  8.                                 ------------------
  9.     xpkMASH is (C) Copyright 1994 by Zdenek Kabelac.
  10.  
  11.     This package may be freely distributed, as long as it is kept in its
  12. original, complete, and unmodified form.  It may not be distributed by itself
  13. or in a commercial package of any kind without my written permission.
  14.  
  15.     xpkMASH is distributed in the hope that it will be useful, but WITHOUT ANY
  16. WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
  17. PARTICULAR PURPOSE.
  18.  
  19.  
  20.                                  Instalation
  21.                   -----------
  22.  
  23.      Make sure the directory libs:compressors does exist and then just copy
  24.  xpkMASH.library to libs:compressors.  You also need to have the XPK package
  25.  installed, it is available from several sources including Fish disks.
  26.  
  27.  
  28.                   Description
  29.                   -----------
  30.  
  31.      xpkMASH is an XPK compression sublibrary whose main purpose is to
  32.  decrunch fast and have an excellent crunch factor.  The sublib is using
  33.  LZ77 compression and a special method to write matches...  MASH now
  34.  normally uses 256KB for its tables, but reduces the size of the
  35.  hashtable if memory is scarce.  (it could crunch even with 64KB+4KB)
  36.  Compressing with a small hashtable naturally is very very slow.
  37.  Default chunk size is 64KB.  The compressor uses lazy match evaluation
  38.  which slowed it down quite a bit.
  39.  
  40.    This sublibrary has several modes:
  41.  
  42.          Mode          Strings to be searched
  43.         ------        ------------------------
  44.           0-09        1     ;high speed - but low CF
  45.      10-19          2
  46.          20-29          4
  47.      30-39          8     ;good for most executables
  48.          40-49         16
  49.      50-59         32
  50.      60-69         64
  51.          70-79        128     ;this should be used for text files
  52.          80-89        256
  53.          90-99        512
  54.         100          1024     ;the best, the slowest
  55.  
  56.  The second column is showing, how many matches should be compared
  57.  - the more searched strings - the better results you will get.
  58.  formula is simple 2^(MODE/10).
  59.  MODE 60 is now runing as fast as NUKE on my A1200
  60.  and if you want to use some higher modes - you will get result better
  61.  for only a few bytes, but slowdown will be very noticeable.
  62.  (But for crunching I'm always using the best mode anyway :-))
  63.  
  64.               !!! The source for this version is not released !!!
  65.     if you want to see it anyway, send me an e-mail and I will send you it.
  66.  
  67.  I still want to do some improvements. Probably even change format of stored
  68.  data to reach better decrunch speed and possibly use some MC68020
  69.  instructions in this case. You don't have to worry, this library will also
  70.  decrunch old format. Send me an e-mail what you'd like to see in newer
  71.  version of this library. But this newer format will always need
  72.  256KB of memory so it could be a problem for some people.
  73.  If you think this library is worth some money, you could send them
  74.  It will speed up development :-)
  75.  
  76.  Sorry, but no bechmarks for the fast packing version now.
  77.  Decruncher has the same speed
  78.  Slow packing cruncher has this speed (its activated when is not possible
  79.  to allocate 256KB of RAM for large buffer):
  80.  
  81.  Evaluated on a A3000/30/25 with 2MB ChipMem and 4MB SCRAM [standard
  82.  XPK benchmark system] by XBench using AmigaVision [594712 bytes]
  83.  
  84.               Orig Packed    CF      Time    KB/s   Decrunch   KB/s
  85.  mash.100   594712 313908 47.3%     65.42    9090      1.42  418811
  86.  mash.000   594712 332652 44.1%      8.59   69233      1.47  404565
  87.  
  88.                            "Thank you"s must go to:
  89.                            ------------------------
  90.  Urban Dominik Mⁿller    <umueller@amiga.icu.net.ch>
  91.    for XPK standart.
  92.  
  93.  Christian von Roques <roques@ipd.info.uni-karlsruhe.de>
  94.    for correcting some parts of this document file,
  95.    and also for releasing his source, so I could use some parts
  96.    of it in my library (xpk interface).
  97.  
  98.  Karsten Dagef÷rde <dagefoer@ibr.cs.tu-bs.de>
  99.         (perhaps, insert diana. after @ !?)
  100.    for making benchmarks
  101.  
  102.  more people should be in this list - authors of Zip, Lha, Arj, ...
  103.  but I would have to make some deep research for them.
  104.  
  105.                     History
  106.  V0.5   Many errors, the biggest problem was bad writing of bits string.
  107.  
  108.  V0.7   Most of errors has been debuged
  109.  
  110.  V0.8   Last byte has not been saved
  111.  
  112.  V0.9   On the first look normaly working version of the sublibrary with
  113.         fixed hash table - size 64KB
  114.  
  115.  V1.0   The big improvement in memory allocating
  116.         memory is allocated before each chunk compresion and deallocated
  117.         after this chunk is compressed (usefull if you have installed
  118.         statram.device)
  119.  
  120.  V1.01  Hash size was increased from 64KB to 128KB (16 bits)
  121.  
  122.  V1.05  Hash is allocated dynamicaly - when is large memory free - large hash
  123.         is used. Starting with 128KB, 64KB, 32KB, .... ,512 bytes
  124.  
  125.  V1.15  Seems to work perfectly for me
  126.  
  127.  First public release:
  128.  
  129.  V1.16  I suppose last bug has been removed - value of register D4
  130.         was not saved on return. Also most of long word instruction has
  131.         been rewritten to word oriented instructions (useful for MC68000)
  132.  
  133.  V1.26  Several speed up improvements - decompression goes about 50 kB faster
  134.  
  135.  Unreleased
  136.  
  137.  V1.30  New crunch mode - uses 256KB of memory for its buffers
  138.  
  139.  V1.40  Removed checking of two bytes in match
  140.         its not needed when two byte hash is used
  141.  
  142.  V1.53  Removed zero length write when chunk is uncrunchable
  143.         Diavolo is a little bit odd and uses this value for DIVS
  144.         even when its not valid -> caused GURU
  145.  
  146.  V1.61  Removed bsr call from scaning rutine.
  147.  
  148.  Released
  149.  
  150.  V1.77  Prepared for release - there is still many things to improve,
  151.         but it has already very good speed. So I'm releasing this
  152.         version.
  153.  
  154.  
  155.                                  Contact Address
  156.                                  ---------------
  157.          Policna 135
  158.   757 01 Valasske Mezirici
  159.       Czech republic
  160.          <kabi@informatics.muni.cz>